Créer un nouveau service avec systemd

Ce tutoriel décrit la démarche à suivre pour transformer un programme en un service systemd pouvant être lancé automatiquement au démarrage du système.

• Disposer des droits d'administration
• Savoir utiliser le terminal
• Avoir systemd comme gestionnaire de service installé (à partir de Xenial)

Comme Upstart, systemd utilise des fichiers de configuration correspondant aux différents services à manipuler. Il n'est (en général) plus nécessaire de créer des fichiers bash pour gérer le service, systemd s'occupe de tout (lancement, arrêt, redémarrage, status, gestion des logs, etc)
Ces fichiers de configuration se trouvent dans /etc/systemd/system/ et permettent d'indiquer les conditions d'activation ou désactivation d'un service, leur propriétaire, etc.

sudo cp -r /etc/systemd/system /etc/systemd/system.save$(date +%Y%m%d)

Une fois le fichier de configuration de service crée, il faut l'activer pour qu'il soit pris en compte par le système et lancé à chaque démarrage.

systemctl enable <nom du service>.service

On peut ensuite le lancer pour test et contrôler sa bonne marche avec les commandes suivantes :

systemctl start <nom du service>.service
systemctl status <nom du service>.service

Pour plus d'infos sur les diverses commandes de gestion, voir la page systemd

Systemd defini differents types de services :

• Un service de type simple (type par défaut) lance un processus principal. Dans le cas où ce processus offre une fonctionnalité à d'autre processus sur le système, ses canaux de communication doivent être installés avant que le processus principal soit démarré. Ce qui est rendu possible par l'activation des sockets, et autres canaux de communication. Ainsi, systemd peut traiter les autres unités sans se préoccuper de la fin du lancement d'une unité de type "simple".
• Un service de type forking, lance un processus père qui créera un processus fils dans le cadre de son démarrage. Le processus parent est prévu pour s’arrêter une fois le démarrage complet et que tous les canaux de communication sont mis en place. Le processus fils continue à fonctionner en tant que le processus principal du service. systemd poursuit le traitement des autres unités une fois que le processus père se termine. Ce type de service correspond aux services UNIX traditionnels.
• Un service de type oneshot est similaire à un service de type simple. Cependant, systemd attend que le processus se termine avant de continuer ses traitements. Ce type de service est typiquement utilisé comme équivalent aux commandes lancées au démarrage via les scripts d'init system V. Cela permet à systemd de remplacer ce mécanisme. De ce fait, avec systemd des nouveaux services apparaissent, alors qu'ils auraient été simplement des scripts d'init avec SysVinit.
• Un service de type dbus est similaire à un service de type simple. Cependant, le processus du service doit obtenir un nom via D-Bus. systemd pourra alors traiter les autres unités.
• Un service de type notify est similaire à un service de type simple. Cependant, c'est le processus du service qui avertira systemd (via la fonction sd_notfy(3)) qu'il peut traiter les autres unités.

Un exemple est le service iptables. Voici un extrait de son fichier de configuration :

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/libexec/iptables.init start
ExecStop=/usr/libexec/iptables.init stop 

• ExecStart permet d'indiquer la commande à exécuter au lancement du service. Ce paramètre est obligatoire pour tout les types de service.
• ExecStop permet d'indiquer une commande a exécuter pour arrêter le service. Ce paramètre est facultatif.
• RemainAfterExit à la valeur "yes" permet d'indiquer que quand la commande de lancement (ExecStart) est terminée, le service est considéré comme toujours lancé. Ce paramètre est très utile pour les services de type "oneshot" qui exécutent une commande à leur lancement (ExecStart) sans qu'il y ait un processus spécifique qui reste en exécution.

• A son lancement, la commande /usr/libexec/iptables.init start est exécutée. Cette commande va permettre de charger des modules iptables et les règles iptables que le modules netfilter du noyau linux va prendre en compte.
• A son arrêt, la commande /usr/libexec/iptables.init stop est exécutée. Cette commande va permettre de remettre en place la politique de traitements iptables par défaut et de décharger les modules iptables.
• Le service iptables continuera d'apparaitre comme actif après la fin de la commande /usr/libexec/iptables.init start et jusqu’à ce qu'il soit explicitement arrêté.

Un exemple est le service deluged qui permet de lancer le service correspondant à la version deamon du client bit-torrent deluge.

/etc/systemd/system/deluged.service

[Unit]
Description=Deluge Bittorrent Client Daemon
After=network-online.target
 
[Service]
Type=simple
 
User=deluge
Group=deluge
UMask=007
 
ExecStart=/usr/bin/deluged -d
 
Restart=on-failure
 
# Configures the time to wait before service is stopped forcefully.
TimeoutStopSec=300
 
[Install]
WantedBy=multi-user.target

• Description permet de donner une description du service qui apparaîtra lors de l'utilisation de la commande systemctl status <nom_du_service>
• After permet d'indiquer quel pré-requis est nécessaire pour le fonctionnement du service. Ici, on indique qu'il faut attendre que l'ordinateur ait accès à Internet pour lancer le daemon. à vérifier : Si l'accès à Internet est perdu, le service est arrêté automatiquement.
  
• Type permet de specifier le type de service
• User, Group et Umask permet d'identifier qui est le propriaitaire du processus et donc les attributs des fichiers téléchargés. Ici, les fichiers téléchargés seront accessibles en Lecture/Ecriture à l'utilisateur Deluge et aux membres du groupe Deluge et invisibles aux autres utilisateurs du système.
• Restart permet de relancer le service automatiquement en cas de plantage.
• WantedBy permet de spécifier dans quel Target doit être actif le service. Ici, en spécifiant multi-user.target, le service est actif dans les Runlevels 2, 3, 4 et 5. Pour en savoir plus sur les Targets, consultez la page de systemd
  

Il est possible de créer plusieurs services à partir d'un même modèle. Par exemple, la gestion des consoles est gérée par un seul modèle getty@.service qui est décliné en getty@tty1.service, getty@tty2.service, etc pour chacune des consoles tty de votre machine. On peut aussi imaginer des services où chaque instance correspond à un utilisateur de la machine. Par exemple, on peut lancer le service syncthing@.service pour synchroniser en parallèle avec syncthing les fichiers de Toto, Gerard et Milou :

syncthing@.service

[Unit]
Description=Syncthing - Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
Wants=syncthing-inotify@.service
 
[Service]
User=%i
ExecStart=/usr/bin/syncthing -no-browser -no-restart -logflags=0
Restart=on-failure
SuccessExitStatus=3 4
RestartForceExitStatus=3 4
UMask=0002
 
[Install]
WantedBy=multi-user.target

• Wants permet de spécifier une dépendance. Pour connaître les dépendances d'une unité, tapez dans un terminal:

systemctl list-dependencies [<unit>] 

• Ici, le User est %i, soit l'argument qui est passé lors de l'activation du service. Pour créer toute les instances du service pour Toto, Gerard et Milou, il faudra avoir tapé une fois :

systemctl enable syncthing@Toto.service
systemctl enable syncthing@Gerard.service
systemctl enable syncthing@Milou.service

Création du fichier de gestion ⇒ /etc/systemd/system/MAJ0.timer

[Unit]
Description=effectue une mise à jour de l'ordinateur quinze minutes après le démarrage de la machine et  itère toutes les trente minutes.
[Timer]
OnBootSec=15minutes   
# le service démarrera 15 minutes après le démarrage de la machine
OnUnitActiveSec=30minutes  
# le service démarrera toutes les trente minutes après la dernière activation du timer
###    voir toutes les possibilités de choix  dans ce  document http://man7.org/linux/man-pages/man7/systemd.time.7.html
[Install]
WantedBy=timers.target
[Service]
User=XXXXXXXXX  # à renseigner ? root par défaut.
Group=users
ExecStart=/etc/init.d/MAJ0

Création du fichier contenant ce qu'il faut faire donc sous /etc/initi.d/MAJ0 dans cet exemple

#! /bin/sh
date >/var/log/MAJ0.log
echo "Faire les mises à jour" >>/var/log/MAJ0.log
sudo apt install tototo  >>/var/log/MAJ0.log
sudo apt autoremove
echo  "Pas encore trouvé pour informer l'utilisateur de la proposition d'épuration. Donc rien n'est épuré" >>/var/log/MAJ0.log
exit 0 

Avec les commande de gestion assiociées

sudo systemctl start   MAJ0.timer
sudo systemctl status MAJ0.time
sudo systemctl stop  MAJ0.timer
sudo systemctl daemon-reload 
sudo systemctl enable MAJ0.timer 

• systemd sur Wikipedia en français
• Site officiel de systemd
• Fedora et systemd notamment pour la partie Type de service systemd
• Documentation de Syncthing Créer un service systemd pour lancer Syncthing au démarrage (en anglais)
• Documentation de Deluge Créer un service systemd pour lancer Deluge au démarrage (en anglais)

Contributeurs: zarmu